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uses existing public communications network (item 20, figure 
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the customer's PIN. The system includes a data center (item 12) 
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the data center is connected to the communications network 
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the system is a user interface (item 28) connecting authorized 
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After establishing the connection, the user (item 30) enters an 
encrypted session with the secure server (item 14). Next, the 
user logs into the secure server (item 14) using an access ID 
and password. Once validated, the user (item 30) is able to 
conduct an online financial transaction without transmitting the 
user's PIN over the network (item 20). 
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WO 00/46725 PCT/USOO/03017 

SYSTEM AND METHOD FOR CONDUCTING ONLINE FINANCIAL 
TRANSACTIONS USING ELECTRONIC FUNDS TRANSFER AND PUBLIC 
COMMUNICATIONS NETWORKS 

TECHNICAL FIELD 

This invention relates to an online financial transaction system and method, and 
more particularly to a system and method for account inquiry, funds transfer and bill 
payment using existing electronic funds transfer and public communications networks 
without the need to transmit a personal identification number ('TIN") over the public 
communications network.. 

BACKGROUND OF THE INVENTION 
With the rapid growth in popularity of the Internet, it has become almost a necessity 
for banks and other financial institutions to be able to offer their customers the ability to 
conduct basic financial transactions, such as account balance inquiry, transfer of funds 
between accounts and electronic bill payment, without the assistance of a teller. This ability 
permits the financial institution customer to perform financial transactions at the customer's 
convenience rather than during normal business hours. In order to meet this need some 
financial institutions have instituted voice activated telephone response systems which allow 
the customer to call the financial institution and conduct financial transactions after entering 
an ID and validating password. In one existing version of such a telephone system, the 
computer system on which the enabling software resides is connected to an electronic funds 
transfer ("EFT") network, sometimes referred to as an automated teller machine ("ATM") 
network. Valid financial transaction requests entered by the customer through the telephone 
system are then processed through the existing EFT network in a conventional manner. A 
disadvantage of this system is the requirement to use specialized telephone equipment 
having a display. In addition, certain information (account numbers, personal identification 
numbers ("PIN"s), etc.) that is normally encrypted and stored on the back of an ATM card in 
the magnetic stripe is needed for the transaction. Because the customer is using the 
telephone and no card reader is present, the customer is unable to transfer the encrypted 
information during the telephone call. Instead, the information must be stored and 
maintained on a computer system controlled by the financial institution or EFT network. 
The stored information must then be combined with the transaction information obtained 
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from the customer over the telephone and f nnatted into a request messaging stream capable 
of being interpreted by the EFT network. The disadvantage of such a system is that 
financial institutions using this system must convey sensitive customer account number and 
password information to the third party vendor maintaining the computer system which 
processes the requests received via telephone from participating financial institution 
customers. This transfer and storing of sensitive financial information to and by a third 
party poses a potential security risk. 

Another popular method for banking without a teller is through online banking 
services. As more and more financial institutions offer such services to their customers, 
there is increased pressure on small financial institutions such as, for example, community 
banks, not currently offering similar online services to add them in order to compete 
effectively in the marketplace. In a typical online banking system, the financial institution 
hosts its web site on the financial institution's own computer system. In order to do this, the 
bank must purchase hardware such as a server, secure routers, and Internet connections. It 
must then develop custom online banking software. Large financial institutions with the 
requisite monetary and technical support resources were the first to offer online banking 
services to their customers. Because the process of adding online banking services is very 
involved technically and security of the system is always a concern, the larger financial 
institutions were the only entities willing to pay the cost and take on the risk associated with 
online banking. 

Several steps are involved in developing a custom online financial transaction 
system. First, the financial institution typically selects a third party vendor to assist in the 
identification of hardware to be purchased as well as in the design and development of the 
online system. Even if the financial institution decides to develop its custom system 
internally, the process is daunting due to the wide range of technical platforms and the 
corresponding variations in cost. If a third party vendor is used, a contract between the 
financial institution and the vendor must be negotiated and signed before work may begin. 
The next step in the process is for the financial institution to work with the vendor in 
developing an interface into the financial institution's core processing system. This 
interface alone could take from 120 to 180 days to develop depending on the design and 
testing requirements. During system development, financial institution staff must be trained 
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to operate the system and to handle questions from customers. Thus, the effort to create a 
custom online financial transaction system from the ground up is enormous and quite costly, 
and this has prevented many small- and medium-sized financial institutions from being able 
to offer the ability to conduct online financial transactions to their customers. 

5 SUMMARY OF THE INVENTION 

The system and method of the present invention makes use of a public 
communications network and at least one EFT network to enable the conduct of financial 
transactions by a financial institution customer or debit cardholder over the networks. This 
is done over a secure connection without transmitting the user's PIN. The system includes a 

10 data center with at least one server and at least one database wherein the data center is 
connected to the communications network and to the EFT network. Also included in the 
system is a user interface connecting at least one authorized user to the communications 
network. The database is used to store data corresponding to financial transactions 
requested by a user that are to be processed by the server and sent over the EFT network 

15 without transmitting the user's PIN. The method of the present invention comprises a user 
connecting to a data center oyer a public communications network through a user interface. 
After establishing the connection, the user enters an encrypted session with the server. 
Next, the user securely logs into the server using an access ID and password that are 
validated before the user is permitted to proceed. Once validated, the user is able to conduct 

20 an online financial transaction without transmitting the user's PIN over the network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. I shows the major components in the present system for conducting authenticated PIN- 
less debits over a public communications network. 

FIGS. 2A and 2B are a flowchart depicting the steps for conducting financial transactions 
25 over the system of FIG. 1 . 

FIG. 3 is a flowchart of the internal processing steps taken by the system of the present 
invention in the debit phase once the user schedules a bill for payment 

FIG. 4 is a flowchart of the submit phase of the present invention and depicts the steps taken 
in conjunction with a bill processor for payment of an electronic bill. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention is directed to a system and method for providing online financial 
transaction services to financial institution debit cardholders and customers who want to 
access their accounts through a public communications network, such as the Internet. 

As shown in Fig. l t the system 10 of the present invention reduces the complexity, 
implementation time and related cost typically associated with developing a custom online 
financial transaction system by taking advantage of two existing systems: a public 
communications network 20, such as the Internet, and an EFT network 22. The term 
"Internet" or (t web" used herein should be understood to mean any public communications 
network. Connected to these two existing systems is a data center 12. An interface access 
28, such as a browser, with the Internet 20 permits a financial institution customer or other 
user 30 to log into a web site hosted on the data center 12 to conduct financial transactions 
such as obtaining account balances, transferring funds, and paying bills electronically 
through the interface 28 to the EFT network 22. The customer interface 28 resides on a 
secure server 14 at the data center 12. Also connected to the data center 12 is at least one 
database 16 for storing customer financial transactions to be processed by the system 10. In 
the preferred embodiment, the server 14 is DEC Alpha server 4100 although any suitable 
computer known in the art may be used. The database 16 used is Oracle 8 Enterprise 
Edition offered by Oracle, although any database running a relational database management 
system and a standard query language such as SQL, 4GL or C with embedded SQL can be 
used. 

The customer interface 28 on the server 14 may be reached either through a financial 
institution's own web site or via a web site maintained by the EFT network provider or its 
third party processor. A bill payment processor 26 is also connected to the data center 12 
through a communication line. The data center 12 is able to process financial transactions 
over the web 20 by utilizing a connection that exists between the data center 12 and the EFT 
network 22. In other words, a separate interface between the data center 12 and each 
individual financial institution 24 is not required since all the necessary financial data is 
obtained directly from the connection between the data center 12 and the EFT network 22. 
Instead of having to develop, maintain and operate a custom interface into each financial 
institution's core processing system, the present invention makes use of a common interface 
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residing on the data center 12 through which financial institution customers 30 can securely 
conduct their financial transactions. In this way, the amount of work needed to bring the 
financial institution online is reduced from an average of 150 days down to a few hours— 
with all the concomitant savings of time and money. 

The present invention has the added advantage of being designed so that each 
financial institution 24 using the system 10 can rely on the security and dependability of the 
existing EFT network 22 for the communications backbone and authorization protocols for 
processing customers' financial transactions. Thus, the invention provides a simpler way to 
connect financial institution customers 30 to their financial institutions using personal 
computers or any Internet access device while maintaining the security needed for 
transmitting sensitive financial information. 

One of the significant features of the present invention is its ability to handle online 
financial transactions by sending a Point of Sale («TOS") request through the EFT network 
22 without sending the user's PIN. This means of sending requests to the EFT network 22 
is possible since the data center 12 is a "trusted" data center. Data center authentication may 
be achieved by quahfying as a SAS-70 Level 2 data center through the instigation of 
procedures necessary to ensure that proper controls for dealing with sensitive financial 
information are in place so as to prevent fraud, especially in the transfer of funds, balance 
inquiries, and payment of bills. SAS-70 Level 2 means that the data center has passed a set 
of stringent security requirements and is therefore a "trusted" data center. The data center 
12 validates each user 30 of the system 10 during login by verifying the customer's access 
ID and password. Each customer's account information is stored on the secure server 14 at 
the data center 12 and is uniquely identifiable through proper entry of the customer's access 
ID and password without use of a customer PIN. Although the customer's debit card 
number is included in the stored information, for security reasons the customer's PIN is not. 
Once the data center 12 has the necessary customer authentication, the EFT network 22 will 
accept requests as PIN-less POS transactions for any authorized customer 30 of any 
financial institution 24 that is connected to the EFT network 22. In this way, transaction 
requests no longer require the information normally stored in the magnetic stripe on an 
ATM debit card to be sent in the message stream from the data center 12 to the EFT 
network 22. More importantly, the magnetic stripe information does not have to be 
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retrieved from the financial institution 24 or stored at the data center 12 and is therefore not 
subject to the risk of disclosure to others. 

Figs. 2 A and 2B are flowcharts of the steps in the operation of the present invention to 
conduct financial transactions over a public communications network 20, such as the 
Internet, through a participating EFT network 22. As shown in Fig. 2A, the user 30, i.e., the 
bank customer desiring to perform an online banking transaction, launches a web browser 
28 at step 32 which permits access to the public communications network 20. The browser 
software (not shown) must be able to handle an encrypted session between the user 30 and 
the data center 12. Typically, the browser runs on a personal computer, and the encrypted 
session is established through SSL (Secure Socket Layer) although any system for achieving 
an encrypted session will suffice. The specific browser software used may also vary and 
includes, for example, text-based browsers, EMAC browsers, Netscape™, Internet 
Explorer™, and Web TV™. Thus, access is not limited to that through a personal computer 
or web-based kiosk but may be made at any location and via any means permitting such 
access. 

The user 30 then connects to the user interface on the data center web site at step 34. 
To do this, the user 30 might access his financial institution's web site or may log into a site 
operated by an EFT network. At step 36, the user 30 will enter an encrypted session with 
the secure server at the data center at which time the secure server sets a cookie on the user's 
browser that is used by the data center to identify the user 30 throughout the session. Next, 
the user 30 logs into the secure server by entering his access ID and password at step 38. If 
the ID and password are valid, the user 30 is presented with a main menu at step 40. If the 
ID and password are not valid, the system denies the user 30 access at step 42. The system 
may permit the user 30 a predetermined number of attempts within a specified time frame to 
correctly enter a valid ID and password before permanently denying access to the system at 
step 44. 

Once the user 30 is authenticated, the user will typically have a range of options 
including accessing customer service at step 46, viewing accounts at step 48, reading 
messages from a financial institution at step 50, authorizing online bill payments at step 52, 
or exiting the system at step 54. Regarding messages the user 30 may receive from the 
system at step 50, the user is notified at the main menu 40 if there are email messages 
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waiting at step 56. The messages may be encrypted if they contain sensitive financial data, 
or they may be unencrypted email messages sent over the public communications network. 
If the user 30 desires, the user may read email at step 58. 

Referring now to Fig. 2B, if the user 30 wants to make a bill payment using the online 

5 system, the user proceeds to the payments page at step 60 where previously entered pending 
bills, if any, for the user are listed and displayed. In addition, this page lists various bill pay 
options. To pay a new bill, the user 30 selects the option to pay a new bill at step 62. 

Paying a bill requires various types of information to ensure that the user's account 
with the proper vendor is credited. The first step in this process is the selection of a vendor 

10 to pay. After the user 30 selects the option to pay a new bill at step 62, the user is presented 
with a vendor query page at step 64 where the user is prompted for information about the 
particular vendor to be paid (e.g., address, name, etc.). Based on the information entered, 
the user 30 can search a database of vendors at step 66 to see if the desired vendor already 
exists in the system. A list of likely vendor matches is presented to the user 30, and then the 

15 user can page through and select the desired vendor to pay at step 68. If the desired vendor 
does not appear in the list at step 68, the user has the option of entering the vendor into the 
system database at step 70. Identifying information such as the vendor's name and address 
is entered in the system. Based on this information, the bill processor 26 (see below) may 
issue a paper check to pay the vendor until such time as the vendor can be added to the 

20 system. 

Next, the system of the present invention chooses a bill processing entity (such as 
Moneyline Express of Minneapolis, Minnesota). For each user's financial institution 24, the 
data center 12 maintains information regarding bill pay priorities for that institution. This 
information is dictated by each financial institution and includes which bill processor 26 it 

25 wishes to use— whether that be Moneyline Express or some other bill payment processor. 
Once a user has requested bill payment be made to a valid vendor, at step 72 the system 
software selects the bill payment processor 26, based on that financial institution's 
preferences, that is able to make a payment from the user to the specified vendor. The next 
step 74 in the process occurs when the user edits, adds and schedules the bill payment 

30 Information such as bill type (one-time or recurring), period, the vendor's account number 
for the user, the user's bank account to be debited for payment, and memo text is added by 
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the user. The system may validate some or all of the information entered by th user into the 
system. Once the user submits the changes or adds the bill at step 78, the payment will 
appear on the vending payment screen (previously described at step 60) with the parameters 
as entered. The editing process may also be used by the user at step 76 on any pending bill 
displayed on the vending payment screen, including on the bill just added. The user may 
then add another payment, edit an existing payment, return to any of the other services on 
the main menu, or log off the system. 

Referring now to Fig. 3, further automated processing of a bill payment by the system 
10 of the present invention is illustrated. When a user schedules a bill to be paid, a debit 
record entry is generated and added to the database 16. The debit record entry contains all 
the information needed for payment of the bill through the EFT network 22. At step 80, 
software running at the data center periodically checks the database 16 where the pending 
bill payment information is stored. The software is designed to detect when a new bill has 
been scheduled for debiting. After detection, the software continues to monitor the bill, and 
when the cutoff time, determined by the financial institution 24 that holds the settlement 
account, is reached, the software retrieves the corresponding bill pay information from the 
debit record entry in the database. At step 84, the bill pay software first verifies that money 
is available in the account from which funds will be withdrawn. If sufficient funds are 
unavailable, the bill is rescheduled for payment on the following day at step 86, and a new 
record reflecting the revised schedule date is added to database 16 for that bill payment 

If funds are adequate to pay the bill at step 84, at step 88 the software creates and sends 
messages to debit the user's account and credit the settlement account, and calls the bill pay 
debit module to process the messages it has created. The software will also create a new bill 
payment record if the bill being paid is a recurring bill such as a mortgage payment. Any 
new bill payment record created in this way is then added to the database 16. The bill pay 
debit software processes the messages formed at step 88 by creating and sending encrypted 
messages to other software, referred to as the ATM software, that runs on the data center 
system at step 90. In the preferred embodiment, the messages begin as ASCII text in a 
generic format that is applicable to a variety of EFT networks. Each message is then 
encrypted with Kerberos with 3DES, developed by MIT and available from MTT under 
license, as it is transmitted within the system and processed by the ATM software. Each 
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message is then translated into the specific IS08583 format before being sent t a particular 
EFT network. Use of ASCII, ISO 8583 and Kerberos with 3DES, however, are not required 
for messaging, and any format and/or encryption technique may be used. The ATM 
software will then route each message to whichever EFT network (Shazam, Pulse, Honor, 
5 etc.) the user or the user's institution utilizes. In the preferred embodiment, the ATM 
software is written in the C++ computer language, and the EFT network is Shazam 
(operated by ITS, Inc. of Johnston, Iowa). At step 92, the receiving EFT network system 
converts messages received from the ATM software to a format accepted by the EFT 
network. In this way, the ATM software is able to interface with multiple EFT networks 
10 serving financial institutions across the nation and even around the world. At this point, 
conventional POS processing by the EFT network takes over at step 94. In particular, the 
user's financial institution receives a message from the EFT network advising the financial 
institution to pull funds from the user's account and credit them into the settlement account 
typically maintained by the EFT network. The funds in the settlement account are 
15 eventually accessed by a bill payment processor, such as Moneyline Express, for actual bill 
payment to the various vendors to be paid as described in more detail below. 

If the funds are available, the transfer occurs through the EFT network at step 96 and 
approval of the transaction is sent back to the originator of the request, i.e., to the data center 
12 at step 98. If sufficient funds are not available, a status message is sent via the EFT 
20 network back to the data center at step 98. Either way, the database at the data center 12 is 
updated at step 100 with information regarding the approval or rejection of the bill payment. 
If the payment was rejected or an error was encountered, the bill is rescheduled for payment 
on the next day. If bill payment was approved, successful completion of the payment is 
reflected in the database records. Upon the user's next login at step 102, an encrypted 
25 message is sent to the secure server from the database informing the secure server of the 
status of the bill payment at step 104. The bill payment screen is then updated for viewing 
by the user at step 106. In this way, users are notified on the bill payment screen regarding 
any problems encountered in paying a bill through the system 10. That way, the user has the 
opportunity to correct any errors in the attempted bill payment. Furthermore, data regarding 
30 the processing of a bill is constantly logged so that the precise "path" taken by a particular 
bill through the system can be investigated if needed. 
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Whenever the database records are updated to reflect that a bill payment was properly 
debited in the EFT network, additional steps are required so that the bill pay processor 26 
can pay the necessary vendors and so that the user will receive the necessary recognition 
that the user's account has been paid. As shown in Fig. 4 at step 108, a submit record is 
created and added to the database 16 whenever an approval for payment has been received 
from the EFT network. This record is similar to the debit record described earlier. The 
software running at the data center 12 constantly monitors the database for submit records 
and will gather all submit records for a particular bill payment processor 26 at step 110. 
Before sending a request to the payment processor, the software obtains the necessary 
vendor (name, address, etc.) and user (name, account with vendor to be credited, amount of 
payment, etc.) information. Information for all such bills to be paid by a particular bill 
processor are retrieved and written to a file in a format prescribed by the payment processor. 
This submit file is then sent to the bill payment processor 26. Once the bill processor 
receives the file at step 1 12, it processes each record in the file. As a record in the submit 
file is processed, the user is kept informed of the status on the bill payment screen via 
communication from the bill processor to the data center which is then used to update the 
database 16. At step 114 the bill processor debits its settlement account for the amount of 
the bill plus any transaction fees associated with the online bill payment, and this status is 
sent back to the data center 12. Next, as shown in step 1 16, the bill processor credits each 
vendor to whom money is owed, and the status of this step is relayed to the data center 12. 
The process is referred to as "sweeping" the money out of the many different customers* 
checking or savings accounts and into the settlement account. 

It is intended that the description of the preferred embodiment of the present invention 
is but one embodiment for implementing the invention. Variations in the description likely 
to be conceived of by those skilled in the art still fall within the breadth and scope of the 
disclosure of the present invention. While specific alternatives to components of the 
invention have been described herein, additional alternatives not specifically disclosed but 
known in the art are intended to fall within the scope of the invention. It is understood that 
other applications of the present invention will be apparent to those skilled in the art upon 
the reading of the preferred embodiment and a consideration of the appended claims and 
drawings. 
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Wc claim: 

1. An online financial transaction system for use with a public communications 
network and at least one EFT network to permit authorized users having PINs to conduct 
financial transactions over the networks with a financial institution electronically connected 
to the communications network and to the EFT network, the system comprising: 

5 a data center connected to the communications network and to the EFT network, the 

data center further comprising: 

at least one secure server, 
at least one database; and 
a user interface connecting at least one authorized user to the communications 
10 network wherein the database contains data corresponding to financial transactions 
requested by a user that are to be processed via the secure server over the EFT network 
without transmitting the user's PIN. 

2. The system of claim 1 and further including: 

a bill payment processor connected to the data center wherein authorized bill 
payments are made by the bill payment processor at the request of the user. 

3. The system of claim 1 wherein the data center is a S AS-70 Level 2 data center. 

4. A method of conducting online financial transactions over a public communications 
network and at least one EFT network to permit authorized users having PINs to conduct 
financial transactions over the networks with a financial institution electronically connected 
to the communications network and to the EFT network, the method comprising: 

5 establishing a communications link to a secure data center server over the public 

communications network via an interface; 

entering an encrypted session with the data center server; 

logging into the data center server with a user's access ED and password pair, 

validating the user's access ID and password pair at the data center server, and 

1 0 conducting an online financial transaction without transmitting the user's PIN. 

5. The method of claim 4 wherein the establishing a communications link further 
comprises pointing a web browser to a financial institution's web site on the Internet 

6. The method of claim 4 wherein the online banking transaction is account inquiry. 
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7. The method of claim 4 wherein the online banking transaction is the transfer of 
funds between user accounts. 

8. The method of claim 4 wherein the online banking transaction is bill payment. 

9. The method of claim 8 further comprising: 
selecting a vendor to pay; 

choosing a bill payment processor; and 
adding bill payment information to the system. 

10. The method of claim 9 wherein selecting a vendor further comprises entering a new 
vendor. 

11. The method of claim 9 wherein selecting a vendor further comprises searching a 
vendor list stored in the data center server based on information entered by the user. 

12. The method of claim 9 wherein choosing a bill payment processor is performed by 
the user. 

13. The method of claim 9 wherein choosing a bill payment processor is accomplished 
by the data center server based on preferences from a financial institution. 

14. The method of claim 9 wherein the bill payment information comprises a bill type, a 
period for bill payment, a vendor-user account number, and a user bank account number. 

1 5 . The method of claim 9 further comprising validating the bill payment information. 

16. The method of claim 9 wherein adding bill payment information farther comprises: 
editing the bill payment information; and 

scheduling a bill payment. 

1 7. The method of claim 9 further comprising: 

generating a new debit record entry corresponding to the bill payment information; 
detecting the new debit record entry; 

monitoring the new debit record entry until a cutoff time is reached; 
retrieving bill payment information from the debit record entry; 
verifying that sufficient funds are available to pay the bill; 

sending messages corresponding to the bill payment information to debit a user's 
account and credit a settlement account; and 

processing the messages for bill payment. 

1 8. The method of claim 1 7 further comprising: 
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updating the database regarding the status of the bill payment. 

19. The method of claim 17 wherein data regarding the status of the bill payment is 
logged in the system. 

20. The method of claim 17 wherein the messages are encrypted and sent to an EFT 
network. 

2 1 . The method of claim 1 7 wherein processing messages occurs over a POS system. 

22. The method of claim 17 wherein processing messages further includes sending a 
message to the user's financial institution to debit funds from the user's account and to 
credit funds to an EFT network settlement account. 

23. The method of claim 22 further comprising accessing the funds in the EFT network 
settlement account for bill payment to designated vendors. 

24. The method of claim 23 wherein accessing the funds is performed by the bill 
payment processor. 
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